NAVAL 

POSTGRADUATE 

SCHOOL 

MONTEREY,  CALIEORNIA 


THESIS 


INTELLIGENT  MAINTENANCE  AID  (IMA) 

by 

Keith  J.  Shockley 

June  2006 

Thesis  Advisor: 

Man-Tak  Shing 

Co-Advisor: 

Michael  Smith 

Approved  for  public  release;  distribution  is  unlimited 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


1  REPORT  DOCUMENTATION  PAGE 

Form  Approved  OMB  No.  0704-0188  \ 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for 
reviewing  instruction,  searching  existing  data  sources,  gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the 
collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  headquarters  Services,  Directorate  for  Information  Operations  and 
Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302,  and  to  the  Office  of  Management  and  Budget, 
Paperwork  Reduction  Project  (0704-0188)  Washington  DC  20503. 

1.  AGENCY  USE  ONLY  (Leave  blank)  2.  REPORT  DATE 

June  2006 

3.  REPORT  TYPE  AND  DATES  COVERED 

Master’s  Thesis 

4.  TITLE  AND  SUBTITLE:  Intelligent  Maintenance  Aid  (IMA) 

5.  LENDING  NUMBERS 

6.  AUTHOR(S)  Keith  J.  Shockley 

7.  PEREORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Naval  Postgraduate  School 

Monterey,  CA  93943-5000 

8.  PEREORMING  ORGANIZATION 
REPORT  NUMBER 

9.  SPONSORING  /MONITORING  AGENCY  NAME(S)  AND 

ADDRESS(ES) 

N/A 

10.  SPONSORING/MONITORING 

AGENCY  REPORT  NUMBER 

II.  SUPPLEMENTARY  NOTES  The  views  expressed  in  this  thesis  are  those  of  the  author  and  do  not  reflect  the  official  policy  or 
position  of  the  Department  of  Defense  or  the  U.S.  Government. 

I2a.  DISTRIBUTION  /  AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  is  unlimited 

12b.  DISTRIBUTION  CODE 

13.  ABSTRACT  (maximum  200  words) 

Technological  complexities  of  current  ground  combat  systems  require  advanced  maintenance  methods  to  keep  the  fleet 
in  a  state  of  operational  readiness.  Currently,  maintenance  personnel  use  paper  Technical  Manuals  (TM)  that  are 
cumbersome  and  not  easily  transportable  or  updated  in  the  field.  This  thesis  proposes  using  the  latest  technology  to 
support  maintainers  in  the  field  or  depot  by  integrating  the  TMs  with  the  onboard  diagnostics  Built-In-Test  (BIT)  and 
Fault  Isolation  Test  (FIT)  of  the  vehicle,  to  provide  the  maintainer  with  an  improved  diagnostics  tool  to  expedite 
troubleshooting  analysis. 

This  will  be  accomplished  by  connecting  the  vehicle,  using  the  vehicle’s  1553  multiplex  bus,  with  the  Graphical  User 
Interface  (GUI)  of  an  Intelligent  Maintenance  Aid  (IMA).  The  IMA  will  use  Troubleshooting  Procedure  (TP)  codes 
generated  during  BIT  and  FIT  testing.  Using  the  information  provided  by  these  TP  codes,  through  the  IMA  GUI, 
information  from  the  technical  manuals  will  be  displayed  to  aid  the  maintainers  in  their  diagnostic  work. 

The  results  of  this  thesis  will  serve  as  a  baseline  for  further  research  and  will  be  presented  to  the  program  management 
office  for  combat  systems  (PM-CS)  for  further  consideration  and  development. 

14.  SUBJECT  TERMS  Built  In  Test  (BIT),  Fault  Isolation  Test  (FIT),  maintenance,  vehicle 
electronics,1553  multiplex  bus 

15.  NUMBER  OE 
PAGES 

83 

16.  PRICE  CODE 

17.  SECURITY 
CLASSIEICATION  OE 

REPORT 

Unclassified 

18.  SECURITY 
CLASSIEICATION 

Unclassified 

19.  SECURITY 
CLASSIEICATION  OE 
ABSTRACT 

Unclassified 

20.  LIMITATION  OE 
ABSTRACT 

UL 

NSN  7540-01-280-5500  Standard  Form  298  (Rev.  2-89) 


Prescribed  by  ANSI  Std.  239-18 


1 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


11 


Approved  for  public  release;  distribution  is  unlimited 


INTELLIGENT  MAINTENANCE  AID  (IMA) 


Keith  J.  Shockley 

Civilian,  United  States  Army  RDECOM-TACOM 
B.S.E.E.,  Eawrence  Institute  of  Technology,  1988 


Submitted  in  partial  fulfillment  of  the 
requirements  for  the  degree  of 


MASTER  OF  SCIENCE  IN  SOFTWARE  ENGINEERING 


from  the 


NAVAL  POSTGRADUATE  SCHOOL 
June  2006 


Author:  Keith  J.  Shockley 


Approved  by:  Man-Tak  Shing 

Thesis  Advisor 


Michael  Smith 
Co-Advisor 


Peter  Denning 

Chairman,  Computer  Science  Department 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


IV 


ABSTRACT 


Technological  complexities  of  current  ground  combat  systems  require  advanced 
maintenance  methods  to  keep  the  fleet  in  a  state  of  operational  readiness.  Currently, 
maintenance  personnel  use  paper  Technical  Manuals  (TM)  that  are  cumbersome  and  not 
easily  transportable  or  updated  in  the  field.  This  thesis  proposes  using  the  latest 
technology  to  support  maintainers  in  the  field  or  depot  by  integrating  the  TMs  with  the 
onboard  diagnostics  Built-In-Test  (BIT)  and  Fault  Isolation  Test  (FIT)  of  the  vehicle,  to 
provide  the  maintainer  with  an  improved  diagnostics  tool  to  expedite  troubleshooting 
analysis. 

This  will  be  accomplished  by  connecting  the  vehicle,  using  the  vehicle’s  1553 
multiplex  bus,  with  the  Graphical  User  Interface  (GUI)  of  an  Intelligent  Maintenance  Aid 
(IMA).  The  IMA  will  use  Troubleshooting  Procedure  (TP)  codes  generated  during  BIT 
and  FIT  testing.  Using  the  information  provided  by  these  TP  codes,  through  the  IMA 
GUI,  information  from  the  technical  manuals  will  be  displayed  to  aid  the  maintainers  in 
their  diagnostic  work. 

The  results  of  this  thesis  will  serve  as  a  baseline  for  further  research  and  will  be 
presented  to  the  program  management  office  for  combat  systems  (PM-CS)  for  further 
consideration  and  development. 
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I.  INTRODUCTION 


A.  BACKGROUND  INFORMATION 

As  the  Army  improves  the  effectiveness  of  its  forces  with  technology,  the 
complexity  of  ground  vehicle  weapon  systems  continues  to  increase.  These  systems 
contain  a  multitude  of  Vetronics  (Vehicle  Electronics)  and  have  become  increasingly 
difficult  to  maintain  and  repair  with  traditional  Army  personnel,  test  equipment  and 
technical  documentation.  Maintaining  these  systems  requires  highly  trained  personnel 
with  in-depth  knowledge  of  embedded  systems.  To  meet  the  maintenance  and  repair 
demands  of  these  systems,  the  Army  must  rely  more  on  technology  and  less  on  humans. 
Future  ground  vehicle  weapon  systems  must  be  designed  to  self-diagnose  and  provide 
test  and  maintenance  interfaces  to  external  test  equipment.  Integrated  maintenance  and 
repair  capabilities  with  advanced  technologies  and  Artificial  Intelligence  (AI)  will 
improve  the  overall  effectiveness  of  the  force. 

These  solutions,  however,  do  not  address  fielded  vehicle  systems.  Presently, 
repairs  are  made,  with  the  help  of  paper  Technical  Manuals  (TM),  at  the  depot  level 
maintenance.  When  these  systems  were  conceived  it  was  not  cost  or  technologically 
feasible  to  provide  comprehensive  embedded  test  and  maintenance  capabilities.  Most 
systems  were  constrained  to  test  connectors  that  provided  limited  test  and  diagnostic 
capability. 

However,  with  the  advent  of  the  Personal  Computer  (PC),  a  powerful  tool 
becomes  available  that  can  be  leveraged  for  fielded  Army  systems  even  though  it  was  not 
envisioned  during  development  of  these  older  systems.  Most  fielded  ground  vehicle 
systems  contain  standard  data  interfaces  such  as  1553,  CAN,  RS232  and  Ethernet;  the 
Army  can  exploit  this  and  utilize  the  PC  to  extract  data  via  these  interfaces.  Most 
systems  with  these  types  of  interfaces  provide  some  level  of  Built-In  Test  (BIT)  and/or 
Fault  Isolation  Test  (FIT)  capability.  The  PC  will  be  configured  to  monitor  the  above 
tests  and  provide  status.  With  this  captured  information,  the  PC  will  analyze  the 
diagnostic  data  and  provide  troubleshooting  and  repair  information  to  maintenance 
personnel.  The  platform,  called  the  Soldier  Portable  On-Site  Repair  Tool  (SPORT), 
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primarily  functions  as  a  software  downloader  with  no  diagnostic/prognostic  capability 
(Figure  1).  The  SPORT ’s  inability  to  provide  a  portable  capability  (in  addition  to 
performing  downloader  duties)  to  perform  diagnostie  tasks  severely  hampers  the 
maintenance  operator’s  ability  to  keep  their  vehicles  in  eonstant  state  of  mission 
readiness. 


SPORT  or  Similar  Imst- 


On-line, 
Hyper-linked 
Tech  manuals 


^^laihtenanceT^ids^^ 
(digital  video  clips, 
Virtual  system  models) 


Combat  platform 
I/F 


Diagnostics 
Manager  and 
User  I/F 


Legacy,  Interim  &  Future  Combat  Platforms 

Figure  1.  SPORT  PC 

B.  STATEMENT  OF  PROBLEM 

Currently,  when  performing  on-board  vehiele  diagnosties,  maintenance  personnel 

rely  on  Technieal  Manuals  (TM)  to  provide  repair  information.  These  TMs  are  usually 

available  only  to  Depot  repair  facilities;  this  greatly  reduees/impairs  the  ability  to  make 

repairs  in  the  field,  espeeially  during  eombat  battlefield  conditions.  For  example,  the 

M1A2  Main  Battle  Tank  is  an  intelligent  system  containing  multiple  mieroproeessors, 

which  have  Built  In  Test  (BIT)  and  Fault  Isolation  Test  (FIT)  eapabilities.  These  tests 

report  failures  to  the  user  interfaces  on  the  Commander’s  Integrated  Display  (CID), 
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Driver’s  Integrated  Display  (DID),  and  Gunner’s  Control  and  Display  Panel  (GCDP). 
Failures  are  reported  with  Troubleshooting  Proeedure  (TP)  numbers  that  are  eross- 
refereneed  with  the  TMs  to  isolate  and  repair  the  failed  system  eomponents.  The  physical 
TMs  are  cumbersome  to  use  and  significantly  add  to  the  time  required  for  diagnosing  and 
repairing  a  vehicle  system.  The  TMs  also  are  updated  on  a  scheduled  basis  with  change 
notices  and,  if  not  updated  regularly,  can  lead  to  misdiagnosis  of  the  problem  and  provide 
faulty  resolutions. 


C.  PROPOSED  SOLUTION 

This  thesis  will  investigate  a  portable  intelligent  solution  for  the  problem  stated 
above.  Providing  an  Intelligent  Maintenance  Aid  (IMA)  that  interfaces  with  ground 
vehicle  weapon  systems  will  satisfy  most  of  the  Army’s  maintenance  requirements  and 
will  surpass  current  maintenance  and  diagnostic  capabilities.  This  will  be  achieved  by 
providing  the  user  with  an  interface  (I/F)  to  the  system  being  evaluated  (in  our  case,  the 
M1A2  tank,  but  it  could  be  any  ground  platform  as  the  concept  diagram  below  depicts). 
The  native  data  bus  will  use  one  of  the  following  standard  protocols:  1553,  CAN,  RS232 
and  Ethernet  to  communicate  to  a  SPORT  or  similar  host.  Once  connected,  the  user  will 
access  IMA  software  to  begin  diagnosing  the  system  under  repair  (see  Figure  2  below). 
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^^Intelligent  Test  Equipment  Demo 


Webbrower-like 

interfae 


File 

Go 

View  Help 

r 

<1= 

&  = 

Go  Back 

1  Forward  Stop 

1  r - 

Manual  Name  Page 

Hull  TP  Number 

Turret  TP  Number 

Run  FIT  Test 

PESl'Jp  1 

TM9-2350-288-20-1-1  a 

|tP004 

1  TP  001  2. 
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TP  605 


± 
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S(ai(  Exploring  -  C:\ITE 


TP  605 
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+  lf  pulse  jet  system:  A 

+  If  pulse  jet  syst^ 
Procedure  (cage  3- 
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+  Do  TP  700  Follow- 

AZ  SERVO  3rd  st^LVDT  out 
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TP  701 

+  Do  TP  701  Follow- 

EL  SERVO  3rd  stage  LVDT  out 
of  range  fault 

9-2350-288-20-2. 

TP  720 

+  DoTP  720  Follow- 

MOSS  ARMED  and  SAFE  both  ON 
or  both  OFF  at  same  time 

9-2350-288-20-2. 

nnlelligent  Tes(  Equip.. 


5:10  PM 


HThL  1 00%  p^  link 


Figure  2.  IMA  Screen  Shot 


The  basic  IMA  system  will  automate  the  use  of  TMs.  The  approach  will  be  to 
utilize  the  current  TMs  that  have  been  captured  electronically  in  Adobe  Acrobat.  The 
electronic  TMs  for  the  Hull  and  Turret  will  reside  on  the  hard  drive  of  the  computer  that 
hosts  the  IMA.  We  will  develop  algorithms  to  search  the  documents  for  the  TP  numbers 
that  are  reported  by  the  M1A2  system. 
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D,  THESIS  ORGANIZATION 

This  chapter  gives  a  brief  deseription  of  the  problem  addressed  by  the  thesis  and 
diseusses  a  solution  to  this  problem,  using  the  IMA  to  aid  maintenanee  personnel.  It  also 
provides  a  high  level  introduction  into  the  on-board  diagnostics  of  the  Ml  A2  Main  Battle 
tank. 

Chapter  II  presents  an  overview  of  the  MI  A2  hardware  and  software  architeeture. 
It  explains  how  the  M1A2  tank  system’s  eomputational  eomponents  are  eonnected  via  a 
MIL-STD-1553  data  bus.  The  ehapter  also  introduees  a  primer  into  the  operational 
characteristics  of  the  MIL-STD-1553  data  bus. 

Chapter  III  contains  the  requirements  and  design  for  the  Intelligent  Maintenanee 
Aid  (IMA).  The  design  ineludes  several  elements  of  the  Universal  Modeling  Language 
(UML);  Use  Case  diagrams,  System  Context  Diagram,  and  a  Conceptual  model. 

Chapter  IV  consists  of  a  detailed  discussion  of  the  proposed  software  architecture 
of  the  IMA  projeet. 

Chapter  V  contains  the  test  and  evaluation  of  the  IMA  project. 

Chapter  VI  discusses  the  lessons  learned  and  draws  a  eonclusion. 
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II.  ABRAMS  MAIN  BATTLE  TANK  (AN  OVERVIEW) 


A.  M1A2  SYSTEM  ARCHITECTURE 

The  Ml  A2  tank  system  architecture  provides  for  the  interconnection  of  a  series  of 
distributed  Line  Replaceable  Units  (LRUs)  via  a  power  distribution  and  data  distribution 
network.  The  M1A2  system  architecture  is  based  on  a  dual  redundant  data  and  utility  bus 
design.  The  primary  computational  system  components  are  interconnected  via  a  Mil-Std 
1553B  Data  Bus  that  provides  digital  communication  between  tank  components.  The 
utility  bus  is  used  for  power  management  and  provides  the  digital  communication 
required  to  control  power  at  various  system  components  and  loads.  The  hull  and  turret 
system  components  are  separated  via  a  slip  ring  that  provides  for  a  continual, 
uninterrupted,  reliable  connection  for  electrical  circuits  as  well  as  air  and  hydraulics.  The 
baseline  M1A2  system  architecture  is  depicted  below  in  Figure  3. 


cnv 


Fcaj  ■  OPS 


uwmrmv* 


I  -Wr  .cr 


Figure  3.  M1A2  System  Diagram 
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The  M1A2  system  diagram  is  intended  to  identify  the  primary  eomputational 
system  elements  and  their  interconneetions  and  is  not  intended  to  identify  the  complete 
system  architecture. 


B,  M1A2  HARDWARE  ARCHITECTURE 

The  M1A2  is  comprised  of  a  series  of  primarily  VME  based  LRUs,  which  are 
functionally  allocated  to  perform  various  system  tasks,  described  below. 


LRU 

Description 

CITY 

The  Commander’s  Independent  Thermal  Viewer  (CITY)  provides 
the  tank  commander  with  an  independent  stabilized  thermal  sight 
with  continuous  360-degree  surveillance.  The  CITV  also  provides 
for  hunter/killer  capability,  selected  sector  autoscan,  search  and  gun 
line  of  sight  modes,  and  a  backup  firing/sight  system. 

LCEU 

The  Lire  Control  Electronics  Unit  (ECEU)  provides  for  fire  control 
system  integration  through  stabilization  control,  weapon  firing 
control,  operating  state  control,  ballistic  offset  insertion,  and  ballistic 
parameter  collection. 

GPS 

The  Gunner’s  Primary  Sight  (GPS)  is  coordinated  with  the  ECEU  in 
order  to  provide  for  gun  LOS,  gun  control,  thermal/optics  control 
and  range  data. 

H/TEU 

The  Hull/Turret  Electronics  Unit  (H/TEU)  perform  various  primary 
and  backup  system  control  functions  listed  below. 

CID 

The  Commander’s  Integrated  Display  (CID)  provides  for  all 
operator  Command,  Control,  and  Communication’s  functions.  This 
includes  IVIS/RIU  and  SINCGARS  operation  as  well  as  the 
preparation  and  disposition  of  tactical  information.  In  addition,  the 
CID  also  provides  for  the  controls  of  the  CITV  and  the  display  of 
both  CITV  imagery  and  system  BIT  status. 

RIU 

The  Radio  Interface  Unit  (RIU)  provides  an  interface  between  the 
Single  Channel  Ground  Airborne  Radio  System  (SINCGARS)  and 
the  core  vehicle  electronics.  The  RIU  provides  for  control  of  the 
SINCGARS  transmitter,  receiver,  and  crypto  functions,  manages  the 
radio  net,  processes  and  manages  radio  message  packets, 
algorithmically  corrects  transmission  errors,  and  performs  built  in 
test. 

GCDP 

The  Gunner’s  Control  and  Display  Panel  provides  for  the  selection 
of  ammo  sub  designate  for  the  currently  selected  round,  allows 
manual  entry  of  sensor  inputs  for  ballistic  computations,  provides 
GCDP  panel  built  in  test,  and  provides  lETE,  CEE,  and  DSESTS 
test  interface. 
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ERU 

Description 

DECU 

The  Digital  Electronics  Control  Unit  (DECU)  provides  for  the 
primary  interaction  with  and  control  of  the  vehicle  engine.  The 

EAJ6  DECU  provides  a  1553  system  interface,  which  is  utilized  for 
systems  interfacing  and  application  downloading  via  the  software 
loader  verifier. 

POS/NAV 

The  Position  Navigation  Unit  (POS/NAV)  provides  the 
commander/driver  navigation  functions  with  tank  heading  and 
position  data.  In  addition,  the  POS/NAV  unit  provides  tank  azimuth 
angular  rate,  tank  pitch  and  roll  angles  for  dynamic  cant  generation, 
and  allows  startup  with  self-initialization,  stored  heading,  or 
manually  input  heading. 

HPDU 

The  Hull  Power  Distribution  Unit  (HPDU)  controls  power  to  the 
Remote  Switching  Modules  (RSMs),  controls  power  to  the  Power 
Control  Modules  (PCMs),  provides  power  and  switching  to  localized 
loads,  houses  the  vehicle  NATO  slave  receptacle,  and  controls 
master  power  via  the  primary  power  interrupter. 

DID 

The  Driver’s  Integrated  Display  (DID)  provides  engine  and  vehicle 
automotive  command,  engine  control  unit  display,  vehicle  heading 
and  steer  to  functions,  drivers  built  in  test. 

Table  1.  Primary  and  Backup  Systems 


The  CID,  DID,  GCDP,  RIU,  H/TEU,  FCEU,  and  POS/NAV  ERUs  form  the  core 
system  computing  environment  for  the  M1A2  baseline. 

The  M1A2  system  is  comprised  of  additional  components,  not  identified  here. 
Most  of  these  components  are  hardware-based  units  providing  additional  system 
inputs/output  data  and  control.  These  components  include  position  sensors, 
ballistic/environment  sensors,  analog  input  modules,  remote  switching  modules,  and 
operator  handles/s  witch  panels. 


C.  M1A2  SOFTWARE  ARCHITECTURE 

The  M1A2  software  is  partitioned  to  functionally  match  the  M1A2  system  design. 
The  software  is  subdivided  into  Computer  Software  Configuration  Items  (CSCIs),  which 
correspond  to  each  MIA2  system  ERU  capable  of  performing  computational  data 
processing.  A  CSCI  is  further  divided  into  Computer  Software  Components  (CSCs), 
which  map  to  major  system  functions  and  are  resident  on  the  various  processors 
contained  within  each  system  ERU.  The  CSCs  are  further  subdivided  into  Computer 
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Software  Units  (CSUs),  which  implement  required  CSC  functionality.  The  software 
functional  mapping  to  M1A2  system  LRUs  for  the  baseline  M1A2  is  depicted  below  in 
Figure  4  (TARDEC  2002). 


The  M1A2  baseline  software  was  primarily  programmed  utilizing  Mil-Std  1815, 
the  Ada  Programming  Language.  MC68020  assembly  language  and  ANSI  C  were  also 
used. 


D,  MIL-STD-1553  DIGITAL  TIME  DIVISON  COMMAND/RESPONSE 
MULTIPLEX  DATA  BUS 

1,  Hardware  Description 

The  1553  MUX  Bus  uses  a  dual-redundant  bus  configuration  (A  and  B).  Each 
bus  uses  a  78-Ohm  twisted,  shielded,  pair  cable  with  78  Ohm  terminators.  Terminal 
equipment  is  transformer  isolated  (TARDEC  2002). 
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2,  Protocol  Description 

All  message  transfers  are  twenty  bit-time  events  at  1  MHz.  The  first  three  bits  are 
synchronization,  the  next  16  bits  are  message  data  content,  and  the  last  bit  is  parity. 


SO 

SI 

S2 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

P 

The  synchronization  waveform  for  the  Command  and  Status  Words  is  an  invalid 
Manchester  of  three  bits  duration;  positive  for  VA  bit  times  and  negative  for  IV2  bit  times. 
The  synchronization  waveform  for  Data  Words  is  inverted.  The  bit  parity  for  all  words 
will  be  an  "Odd  Ones"  on  the  16  data  bits. 


Data  Bit  Word  Syn:  Data  Bit  Data  Bit  Word  Syno  Data  Bit 

3.  1553  Data  Bus  Message  Content 

The  data  code  is  Manchester  II  bi-phase.  A  logic  one  will  be  transmitted  as  a 
bipolar  coded  signal  of  1/0  (i.e.,  a  positive  pulse  followed  by  a  negative  pulse).  A  logic 
zero  will  be  a  bipolar  coded  signal  of  0/1  (i.e.,  a  negative  pulse  followed  by  a  positive 
pulse). 

Bit  values  of  the  data  content  of  each  message  will  be  from  MSB  to  LSB,  in  the 
order  received. 
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4.  1553  Data  Bus  Command  Word 

The  data  content  of  the  Command  Word  generated  by  the  Bus  Controller  (BC)  to 
the  Remote  Terminal  (RT)  has  the  RT  address  in  the  upper  (most  significant)  live  bits, 
followed  by  the  Transmit/Receive  bit,  the  five-bit  message  sub  address/mode  field,  and 
the  five-bit  data  word  count/mode  code  field. 


15  14  13  12  11 

10 

9  8  7  6  5 

4  3  2  1  0 

Remote  Terminal  Address 

TR 

Message  Sub  address/Mode 

Data  Word  Count/Mode 
Code 

No  Data  Words  follow  the  Command  Word  if  the  Transmit/Receive  bit  is  set 
(Transmit).  Bits  five  through  nine  indicate  either  a  message  sub  address  (“00001” 
through  “11 110”)  or  flag  a  mode  code  in  bits  zero  through  four  (“00000”  or  “1 1 1 11”).  If 
a  receive  message  sub  address  is  indicated,  a  data  word  count  (“00001”  through  “11111”, 
and  “00000”  for  32)  appears  in  bits  zero  through  four.  If  a  mode  command  is  indicated, 
the  RT  bus  terminal  hardware  traps  it  and  responds  appropriately. 

The  data  content  of  the  Data  Words  which  accompany  the  Command  Word  when 
the  Transmit/Receive  bit  is  reset  (Receive)  have  the  appropriate  content  for  that  message 
as  described  in  Data  Packet  Specifications  Volume  1  through  11,  DP-SA15132  Data 
Packet  Specifications  for  M1A2  Main  Battle  Tank. 

5.  1553  Data  Bus  Status  Word 

The  Status  Word  from  the  RT  to  the  BC  has  the  RT  address  in  the  upper  five  bits, 
the  Message  Error  bit  in  10,  The  Instrumentation  bit  in  nine,  the  Service  Request  bit  in 
eight.  The  Broadcast  Command  Received  bit  in  four,  the  Busy  bit  in  three,  the  Subsystem 
Flag  in  two,  the  Dynamic  Bus  Control  Acceptance  bit  in  one,  and  the  Terminal  Flag  in 
zero.  Bits  nine,  five  through  seven,  three,  and  one  will  be  logic  zero  as  these  bits  are  not 
currently  utilized. 


15 

14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

I 

0 

Terminal  Address 

ME 

IN 

SR 

BR 

B 

SF 

DC 

TF 

12 


The  Message  Error  bit  is  set  by  the  RT  after  a  Command  Word  with  an  invalid 
message  sub  address  and  Transmit/Reeeive  eombination,  or  if  a  reeeive  message  is  short 
of  its  Data  Word  eount,  failed  word  parity  validation,  has  improperly  timed  data 
synehronization,  or  has  non-eontiguous  data.  If  the  Message  Error  bit  is  set,  it  is  eleared 
for  the  next  message,  barring  subsequent  errors.  The  Instrumentation  bit  is  undefined. 
The  Service  Request  bit  is  set  by  the  RT  to  initiate  a  transmit  or  receive  transaction.  The 
Broadcast  Command  Received  bit  is  set  when  the  preceding  valid  command  is  a 
broadcast  command.  The  Broadcast  Command  Received  bit  is  reset  when  the  next  valid 
command  is  received,  except  in  the  cases  of  a  transmit  status  word  and  transmit  last 
command.  The  Busy  bit  is  set  by  the  RT  when  no  further  messages  can  be  processed 
until  the  busy  condition  is  cleared.  The  Subsystem  Elag  is  set  to  when  a  fatal  operating 
fault  occurs  in  the  RT.  The  Dynamic  Bus  Control  Acceptance  bit  is  used  by  alternate 
BC’s  only.  The  Terminal  Elag  bit  is  set  by  the  RT  if  the  Message  Error,  Service  Request, 
or  Busy  bits  are  set.  The  Terminal  Elag  is  set  for  a  fatal  operating  fault  condition  in  the 
RT  bus  terminal  hardware. 

6,  1553  Data  Bus  Data  Word  with  Status  Word 

The  data  content  of  the  Data  Words  which  accompany  the  Status  Word, 
regardless  of  the  Service  Request  bit  setting,  when  the  preceding  Command  Word  was  a 
transmit  command  will  have  the  appropriate  content  for  that  message. 

The  data  content  of  the  Data  Word  which  accompanies  the  Status  Word  when  the 
Service  Request  bit  is  set  and  the  preceding  Command  Word  was  not  a  transmit 
command  will  have  zeros  in  the  upper  five  bits,  the  Transmit/Receive  bit  in  10,  the  five- 
bit  message  sub  address  field  in  five  through  nine,  and  the  five-bit  data  word  count  field 
in  zero  through  four.  This  status  response  conformation  is  used  only  when  an  RT 
requires  an  exception,  rather  than  periodic  servicing. 
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7,  1553  Data  Bus  Message  Transfer 

Inter-message  gap  and  RT  response  times  depicted  are  consistent  with  the 
requirements  of  MIL-STD-1553B. 

EltTIne  EltTIne 

I  19  I  a  I  I  I  I  2  I  3  I 

Portti’  B  It  Ccfrt  mo  Cy’io 


The  BC  provides  a  minimum  gap  time  of  four  microseconds  between  messages. 
The  RT  responds  to  a  valid  Command  Word  within  a  period  of  four  to  12  microseconds. 
The  minimum  wait  time  between  the  last  Data  Word  of  a  message  transmitted  by  the  BC 
and  the  receipt  of  a  Status  Word  generated  by  the  RT  is  14  microseconds. 

8,  1553  Data  Bus  BC  to  RT  Sequence 

In  the  BC  to  RT  transfer  sequence,  the  BC  transmits  a  Command  Word  with  its 
Transmit/Receive  bit  reset  to  indicate  the  RT  will  receive.  The  Command  Word  is 
followed  by  a  sequence  of  one  to  32  Data  Words  generated  by  the  BC.  The  Command 
and  Data  Words  are  transmitted  in  a  contiguous  fashion  with  no  interword  gaps.  The  RT 
responds  with  a  Status  Word. 
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9. 


1553  Data  Bus  RT  to  BC  Sequence 


In  the  RT  to  BC  transfer  sequence,  the  BC  transmits  a  Command  Word  with  its 
Transmit/Receive  bit  set  to  indicate  the  RT  will  transmit.  The  RT  responds  with  a  Status 
Word  followed  by  a  sequence  of  one  to  32  Data  Words  generated  by  the  RT.  The  Status 
and  Data  Words  are  transmitted  in  a  contiguous  fashion  with  no  interword  gaps. 

10.  1553  Data  Bus  RT  to  RT  Sequence 


In  the  RT  to  RT  transfer  sequence,  the  BC  transmits  contiguously  two  Command 
Words,  one  with  the  Transmit/Receive  bit  reset  to  indicate  the  receiving  RT  and  one  with 
the  Transmit/Receive  bit  set  to  indicate  the  transmitting  RT.  The  Command  Words  are 
followed  by  a  sequence  of  a  Status  Word  and  one  to  32  Data  Words  generated  by  the 
transmitting  RT.  The  Status  and  Data  Words  are  transmitted  in  a  contiguous  fashion  with 
no  interword  gaps.  The  receiving  RT  responds  with  a  Status  Word. 
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III.  REQUIREMENTS  AND  SPECIFICATION 


A.  REQUIREMENTS  FOR  IMA 

This  section  specifies  the  requirements  that  were  used  to  develop  the  IMA 
prototype,  a  real  time  diagnostics  tool  for  repairing  ground  combat  systems.  The  system 
was  designed  to  provide  the  vehicle  maintainer  an  accurate  and  reliable  means  to 
diagnose  and  repair  the  vehicle,  using  the  vehicle’s  own  on  board  diagnostics  capability 
in  conjunction  with  the  technical  manuals  (document  lookup  capability)  and  an  easy  to 
use  Graphical  User  Interface  (GUI).  The  system  also  includes  additional  software  and 
hardware  interfaces  from  SBS  Technologies  for  the  1553  Data  bus  to  provide  remote 
terminal,  bus  controller  emulation  and  interface  to  the  SPORT  or  equivalent  computer 
that  hosts  the  IMA  as  shown  in  Figure  5  below. 


Figure  5.  IMA  Interfacing  with  the  M1A2  tank 

The  IMA  will  be  operating  in  an  environment  with  the  real  TEU  (bus  controller) 
and  real  H/TEU  (Back-up  Bus  controller). 
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1,  System  Goals 

The  IMA  system  shall  be  required  to  provide  real-time  aeeess  to 
teehnioal/maintenanee  doeumentation  enabling  the  user  (maintenanee  personnel  or 
engineers)  for  improved  turn-around/de-bug  time  for  repairs.  The  goals  of  the  IMA  are 
(1)  to  provide  the  user  with  rapid  on-site  repairs  and  (2)  reduee  cost  of  performing 
Combat  Sustainment  Support  (CSS)  without  reducing  war  fighting  capability  or 
readiness. 

The  IMA  is  a  semi-autonomous  system  capable  of  functioning  for  extended 
periods  of  time  with  minimal  maintenance  support.  The  IMA  shall  be  provided  in  a  C  ++ 
runtime-software  package  and  Windows  development  environment. 

2,  Assumptions  and  Dependencies 

The  following  assumptions  and  dependencies  have  been  defined  in  order  to 
simplify  the  development  of  the  IMA; 

•  The  IMA  shall  fully  support  all  known/used  data  bus  configurations. 

•  The  IMA  must  use  current  Soldier  Portable  On-Board  Repair  Tool 
(SPORT  or  equivalent  computer)  platform  as  not  to  increase  of 
development  costs. 

3,  Requirements/Function  Assumptions 

•  The  IMA  shall  be  developed  on/for  Windows  based  platforms. 

•  C++  shall  be  used  in  the  development  of  Intelligent  Maintenance  Aid. 

•  No  special  tools  or  test  measurement  device  equipment  are 
necessary/required. 

•  The  IMA  can  be  operational  24  hours  a  day  provided  the  SPORT  or 
equivalent  computer  device  is  powered  by  an  AC  power  source. 
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B,  SYSTEM  FUNCTIONS 

1.  Required  States  and  Modes 

The  system  shall  be  ready  to  operate  at  all  times.  The  IMA  provides  for  two 
modes  of  operation;  test  mode  or  look-up  mode.  Test  mode  provides  access  to  vehicle 
system  level  BIT  and  FIT  diagnostics  operations  through  data  bus  communications. 
Look-up  mode  provides  access  to  the  on  board  technical  manuals  for  reference. 

2,  System  Capability  Requirements 

a.  User  Input 

The  system  shall  be  capable  of  accepting  user  input  from  buttons  located 
either  at  the  internal  or  the  external  keyboard  on  the  SPORT  or  equivalent  computer. 
Presentation  of  user  input  requests  shall  be  done  through  a  Graphical  User  Interface 
(GUI)  used  on  the  SPORT  or  equivalent  computer. 

b.  Provide  User  Feedback 

The  system  shall  be  capable  of  providing  appropriate  feedback  to  the  user 
through  a  Graphical  User  Interface  (GUI)  used  on  SPORT  or  equivalent  computer. 

c.  System  Response 

The  system  shall  be  capable  at  a  minimum,  of  starting  and  stopping  on 
desired  selection(s). 

d.  Communication  Coordination 

The  IMA  system  will  efficiently  coordinate  communication  between  the 
SPORT  or  equivalent  computer  and  the  vehicle  under  test  by  use  of  data  bus 
communication  ( i.e.,  1553,  RS-232,  etc.). 
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Ref# 

Funetion 

Thesis 

Para.Ref. 

Category 

Use  Case 

Association 

R1 

Rl.l 

Start  SPORT  or  equivalent 
eomputer 

Enter  Log-In  &  Password 

IILB.2.a 

III.B.2.a  & 
IILB.2.b 

Evident 

U1 

R1.2 

Select  IMA  Application 

III.B.2.a, 
IILB.2.b  & 
IILB.2.C 

Evident 

U1 

R2 

R2.1 

Modes  of  Operation 

Test  Mode 

IILB.2.a, 
IILB.2.b  & 
III.B.2.d 

Evident 

U2 

R2.1.1 

Run  BIT  Test  on  vehicle  and  results 
to  be  displayed  on  IMA. 

III.B.2.b, 
III.B.2.C  & 
IILB.2.d 

Evident 

U2 

R2.1.2 

Run  FIT  Test  from  both  the  vehicle 
and  IMA. 

III.B.2.b, 
IILB.2.C  & 
III.B.2.d 

Evident 

U2 

R2.1.3 

IMA  maintains  knowledge  of  TP 
numbers  and  displays  results 

IILB.2.b, 
III.B.2.C  & 
III.B.2.d 

Hidden 

U2 

R2.2 

Look-up  Mode 

III.B.2.a, 
IILB.2.b  & 
IILB.2.C 

Evident 

U2 

Table  2.  System  Funetions 
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Ref# 

Function 

Cat. 

Attribute 

Details  &  Constraints 

Cat. 

Rl.l 

Enter  Fog-In 

Evident 

Security 

(Boundary  Constraint)  Fog- 

must 

&  Password 

access  to  the 

In  and  password  necessary 

IMA  system 

for  restricted  access. 

R2.1 

Test  Mode 

Evident 

Provides  for 

(Boundary  Constraint)  BIT 

must 

BIT  and  FIT 

test  must  be  run  before  FIT 

tests 

test. 

R2.1.3 

IMA 

Hidden 

FRU 

(Boundary  Constraint) 

must 

maintains 

Monitoring 

Results  of  BIT  and  FIT 

knowledge  of 

Tests  and  displays  results. 

TP  numbers 

Must  be  reset  before  other 

and  displays 

test  can  run. 

results 

Programming 

Fanguage 

(Detail)  C++ 

must 

Table  3.  System  Attribute  Table 

C.  USE  CASE  DIAGRAM 

The  USE  case  shown  in  Figure  6  depicts  the  relationship  between  the  actors  (in 
this  case  the  maintenance  operator  and  vehicle  system)  to  the  IMA  system  (Craig  Larman 
1997). 


Figure  6.  High  Fevel  Use  Case 
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D,  USE  CASE  SCENARIOS 


1,  Use  Case  1:  Log  In 


Use  case; 

Log  In 

Actors; 

Maintenance  Operator  (initiators) 

Purpose; 

To  log  in  to  SPORT  or  equivalent  computer  to  access  the 

IMA  System 

Description; 

Maintenance  Operator  provides  password  SPORT  or 

equivalent  computer  to  gain  access  to  the  IMA  system. 

Type; 

Primary  and  essential 

Cross-references; 

R1.1,R1.2 

a.  Typical  Course  of  Events 


Actor  Action 

System  Response 

1 .  SPORT  or  equivalent  computer  requests 

Log  in  and  password. 

2.  Maintenance  Operator  enters  Log  in  and 

password  into  the  SPORT  or  equivalent 

computer. 

3.  SPORT  or  equivalent  computer 

accepts/denies  Log  in  and  password. 

Brings  up  start-up  screen. 

4.  Maintenance  operator  selects  IMA  icon 

to  start  software  application. 

5.  IMA  screen  is  on  and  ready  to  use 
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2,  Use  Case  2:  Run  Test 

Use  case;  Run  Test 

Actors;  Maintenance  Operator  (initiators) 

Purpose;  To  perform  Vehicle  System  BIT  and  FIT  tests. 

Overview;  Maintenance  operator  initiates  test  by  running  Built-In-Test  (BIT) 
on  the  Vehicle  System  diagnostics  menu  first,  then  starts  the  IMA  FIT  monitor  and 
initiate  the  Fault  Isolation  Test  (FIT)  from  the  Vehicle  System  diagnostics  menu. 

Type;  primary,  secondary  and  essential 

Cross-references;  R2. 1 ,  R2. 1 . 1 ,  R2. 1 .2,  R2. 1 .3 

a.  Typical  Course  of  Events 


Actor  Action 

System  Response 

I.  Maintenance  operator  initiates  BIT  test 

from  Vehicle  System  diagnostics  menu. 

2.  Vehicle  System  begins  BIT. 

3.  Vehicle  System  completes  and  displays 

BIT  results  on  IMA. 

4.  Maintenance  operator  starts  the  IMA 

FIT  monitor  and  then  initiates  FIT  test 

from  the  Vehicle  System  diagnostics  menu. 

5.  Vehicle  System  completes  FIT  Test  and 

displays  results  on  IMA  FIT  Monitor  and 

vehicle. 
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E. 


SYSTEM  CONTEXT  DIAGRAM 
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Figure  7.  IMA  System  Context  Diagram 
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Event 

System  Response 

Dir. 

Pat. 

Arrival 

Pattern 

Sync 

Pattern 

Enter  Eog-In  and  Password. 

SPORT  or  equivalent 
eomputer  allows 

aceess  to  IMA 

application  program. 

IN 

Episodic 

Sync 

exeouteTest(BIT) 

Execute  BIT  on  system 

IN 

Episodic 

Sync 

exeeuteTest  (EIT) 

Collects  diagnostic 

data  from  BIT  Test  to 
pass  on  to  EIT  test  for 
TP  look  up  table. 

IN 

Episodic 

Sync 

exeeuteTP  Eook-up  (TP) 

Displays  results  from 
PIT  test  to  TP  look  up 
table. 

IN 

Episodic 

Sync 

reset  (System) 

System  must  be  reset 
to  clear  previous 
results. 

IN 

Episodic 

Sync 

Table  4.  External  Events 


Table  4  deseribes  the  external  events  to  the  IMA  system  based  on  events,  system 
response,  direetion  pattern,  arrival  pattern,  and  syne  pattern. 
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F.  CONCEPTUAL  DIAGRAM 


display  to  initiate  run  on 


Figure  8.  IMA  Conceptual  Diagram 


26 


Intelligent  Maintenance  Aid 

System  Sequence  Diagram 


G.  SYSTEM  SEQUENCE  DIAGRAM 


ro  Q. 

5:  o 


Figure  9.  IMA  System  Sequence  Diagram 
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H,  GLOSSARY 


Term 

Category 

Comments 

Maintenance 

Operator 

Type 

Personnel  responsible  for  maintaining 

Intelligent  Maintenance  Aid  and  associated 

equipment 

Vehicle  System 

Type 

Generic  term  used  for  describing  vehicle 

under  test 

Log-In 

Use  Case 

Description  of  operator  entering  Log-In  and 

password  data 

Run  Test 

Use  Case 

Description  of  operator  performing  BIT  and 

FIT  tests 

Display  BIT  Results; 

Boolean 

Attribute 

Description  of  GO  and  NO  GO  status  of 

LRUs. 

Troubleshooting 

Procedure  Codes 

(TP);  Integer 

Attribute 

Description  of  errors  associated  with 

running  BIT  and  FIT  tests. 

Table  5 .  Glossary  of  T erms 
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IV.  SOFTWARE  ARCHITECTURE  DESIGN 


A.  INTRODUCTION  FOR  EMBEDDED  DIAGNOSTICS  FOR  M1A2  TANK 

Figure  10  presents  a  high-level  view  of  the  Fault  Management  in  a  M1A2  Tank 
(GDLS  S/SDD  2003). 


Figure  10.  Operation  and  Status  of  Fault  Management 


The  System  Level  Diagnosties  is  made  up  of  three  nested  levels; 

•  Self  Test  (ST) 

•  Built-in-Test  (BIT) 

•  Fault  Isolation  Test  (FIT) 


ST  is  the  first  level  of  diagnosties  to  deteet  a  failure.  Upon  deteetion  of  a  failure, 
the  erew  is  made  aware  of  a  failure  eondition  via  the  display  meehanism  deseribed  in  the 
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next  section.  If  ST  detects  a  failure  or  the  crew  suspects  something  is  malfunctioning, 
further  diagnostic  testing  is  essential  since  ST  has  limited  fault  detection  coverage  due  to 
its  non-intrusive  design.  If  the  tank  is  in  Pre/Post  or  Combat  mode,  no  further  testing  is 
permitted  until  the  crew  transitions  the  tank  into  Diagnostics  mode. 

Once  in  Diagnostics  mode,  the  crew  may  initiate  the  execution  of  Built-In-Test 
(BIT)  to  confirm  a  failure  detected  by  ST  or  a  suspected  malfunction.  BIT’s  fault 
detection  is  more  comprehensive  because  it  allows  intrusive  testing  where  necessary. 

When  ST  or  BIT  detects  fault  conditions,  the  tank  crew  informs  organizational 
maintenance  of  the  situation  relaying  the  extent  of  the  failure  information  provided  by  ST 
or  BIT.  Unit  maintenance,  upon  receiving  the  tank  for  problem  resolution,  confirms  the 
existence  of  the  fault  condition  by  executing  BIT  again.  If  the  maintenance  crew 
determines  that  system  BIT  has  isolated  to  a  Line  Replaceable  Unit  (LRU)  level,  the 
faulty  LRU  is  replaced.  If  the  maintenance  crew  determines  that  an  LRU  ambiguity 
group  exists,  the  maintenance  crew  initiates  Fault  Isolation  Test  (FIT).  This  either 
resolves  the  ambiguity  or  confirms  the  existence  of  multiple  failures.  When  BIT  and  FIT 
fail  to  isolate  the  failure  to  an  LRU,  the  unit  mechanic  will  then  resort  to  manual 
troubleshooting  procedures. 

1.  Self  Test  (ST) 

Self-Test  is  the  first  level  of  embedded  diagnostics  within  the  M1A2  tank.  ST 
reports  faults  to  the  crew  during  all  modes  of  operation.  Self-Test  data  runs  in  the 
background  of  each  LRU.  ST  runs  upon  power-up  and  performs  a  health  check  on  the 
system  without  affecting  tank  functions.  Each  LRU,  communicating  on  the  bus,  provides 
health  status  to  the  system.  This  health  status  will  be  interpreted  by  the  system  and 
reported  to  the  crew  in  the  form  of  a  caution  or  warning  pop-up  on  the  appropriate 
displays.  The  10  LRU’s  that  make  up  the  tank’s  architecture  are: 

a.  CID 

b.  DID 

c.  GCDP 

d.  HEU 

e.  TEU 
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f.  POS/NAV 

g.  DECU 

h.  CITY 

i.  FCEU 

j.  Riu 


Each  of  the  above  10  EREl’s  reports  Self-Test  data  on  the  health  of  their  own 
system.  Self-Test  data  from  eaeh  ERU  is  plaeed  on  the  1553  bus  through  data  paeket  30. 
Data  paeket  30  is  the  reporting  meehanism  for  diagnostie  data.  Self-Test  data  is  updated 
on  the  1553  bus  at  a  IHz  rate.  When  an  ERU  deteets  a  failure  within  its  internal 
arehiteeture,  a  bit  will  be  set  in  data  paeket  30  from  that  ERU.  Data  Paeket  30  results 
were  evaluated  by  the  bus  eontroller.  The  TEU  applies  fault  results  to  the  generation 
eriteria  for  Cautions  and  Warnings.  If  the  TEU  fails,  the  HEU  (baekup)  will  take  over 
and  invoke  the  Systems  Eevel  Diagnosties.  If  the  generation  eriteria  are  met,  a  Caution 
or  Warning  will  be  output  from  the  TEU/HEU.  The  TEU/HEU  outputs  Caution  and 
Warning  results  on  the  1553  bus  through  data  paeket  28  (see  Figure  1 1).  Data  paeket  28 
eontains  the  eontinuous  update  of  all  Caution  and  Warnings  and  is  sent  to  all  three 
displays  (CID,  DID,  and  GCDP).  Only  the  Cautions  and  Warnings  that  are  primary  to 
eaeh  display  will  be  shown. 
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Figure  1 1 .  Data  Packet  Flow 

2,  Built-In-Test  (BIT) 

Built-In-Test  is  the  second  level  of  embedded  diagnostics.  BIT  is  an  intrusive  test 
of  the  system  health  status.  BIT  operates  within  the  Diagnostic  mode  of  operation  and 
performs  an  intrusive  test  on  various  units  when  commanded  by  the  operator.  Once  a 
unit  is  under  BIT,  it  will  not  communicate  within  the  system  until  it  has  completed 
intrusive  testing  of  its  internal  architecture.  The  crew  can  perform  a  health  check  of  the 
vehicle  from  all  displays.  From  the  Commanders  display,  the  operator  can  perform  a 
system  BIT  on  all  units.  Once  commanded  into  BIT  each  unit  undergoes  an  intrusive 
testing  of  its  internal  architecture. 

After  completion  of  BIT,  the  tested  units  return  BIT  results,  which  are  displayed 
as  GO  or  NOGO.  BIT  performed  at  the  driver’s  display  will  report  hull-related 
diagnostic  BIT  results  and  the  gunner’s  display  will  report  turret  related  diagnostic  BIT 
status.  BIT  can  also  be  executed  on  the  fire  control  system  by  running  the  FC  SYSTEM 
TEST.  The  fire  control  system  test  can  only  be  run  from  the  GCDP  in  Operational  mode 
with  the  gunners  handle. 
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3.  Fault  Isolation  Test  (FIT) 

Fault  Isolation  Test  is  the  third  level  of  embedded  diagnostics.  FIT  utilizes  the 
results  from  Self-Test  and  Built-In-Test  to  reduce  ambiguity  groups  within  the  system. 
The  corresponding  ST  and  BIT  results  are  incorporated  into  variables.  These  variables 
make  up  several  hundred  Boolean  equations  to  isolate  faulty  units  and  generate 
troubleshooting  procedure  (TP)  numbers. 

Maintenance  crews  can  obtain  a  list  of  faulty  units  through  Fault  Isolation 
Testing.  Once  the  unit  is  deemed  faulty,  the  crew  can  replace  the  unit. 

System  Health  categories  also  show  up  under  FIT.  System  Health  category 
contains: 

a.  Cable  Disconnects 

b.  Power  Management 

c.  Utility  Bus 

d.  Data  Bus  Communications 

e.  Hull  Computer 

f  Turret  Computer  System 

g.  Commanders  Station 

h.  Drivers  Station 

i.  Gunners  Station 

j.  Gun/Turret  Drive  System 

k.  Weapons  System 

l.  Gun  Positioning  System 

m.  Communications  System 

n.  Automotive  System 

0.  Hull  System 


Each  categories  will  display  a  GO  or  NOGO  condition.  If  a  category  is  a  NOGO, 
entering  the  category  will  reveal  corresponding  troubleshooting  procedure  numbers. 
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B,  IMA  PROTOTYPE 

The  IMA  is  a  PC  based  application.  The  application  provides  two  basic 
capabilities:  (1)  a  graphical  representation  of  the  real-time  1553  fault  reporting,  (2) 
HTML  hyperlinked  troubleshooting  procedures  for  detected  failures.  To  provide  these 
capabilities  the  PC  is  equipped  with  a  1553  PCI  card,  existing  TACOM  ATE  software, 
and  maintenance  manual  documentation  in  HTML  format.  The  ATE  software 
(1553GUI)  establishes  transmit  and  receive  buffers  in  the  PC  shared  memory  while  also 
configuring  the  SBS  1553  for  bus  monitoring  of  desired  1553  remote  terminals.  The 
IMA  connects  to  the  PC  shared  memory  to  retrieve  real-time  remote  terminal  fault 
information.  To  provide  “on-line”  hyperlinked  troubleshooting  procedures,  the  IMA 
uses  a  simple  static  relational  database.  Existing  maintenance  manual  documentation 
(pdf  format)  is  converted  to  HTML.  All  page  or  procedure  references  within  all  manuals 
are  parsed  out  and  stored  within  the  database.  All  HTML  files  along  with  the  database 
reside  on  the  local  PC.  Based  on  user  IMA  menu  selections  and  the  database,  appropriate 
systems  manual  pages  containing  the  needed  troubleshooting  procedures  are  presented. 

C.  REAL-TIME  FAULT  REPORTING 

Remote  terminals  in  the  Ml  A2  system  provide  real-time  fault  information  in  sub¬ 
address  (message)  number  30  via  the  1553  data  bus.  Refer  to  Chapter  II  for  the  1553 
protocol  description.  IMA  monitors  this  real-time  data  and  provides  a  graphical 
depiction  of  all  fault  information  via  the  System  Display  Window  (Figure  12).  Fault  data 
for  particular  1553  remote  terminal  are  accessed  by  clicking  on  the  desired  terminal  on 
the  System  Display  Window.  For  example,  selection  the  CID  icon  will  invoke  the  CID 
Display  Window  shown  in  Figure  13. 
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Figure  12.  System  Display  Window 
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Figure  13.  CID  Display  Window 


D.  FAULT  DATA 

In  the  M1A2  system,  message  30  information  is  provided  at  1  FIz  rate.  Message 
30  can  contain  up  to  32  16-bit  data  words.  (Refer  to  Chapter  II  for  the  1553  protocol 
description.)  Specific  fault  data  items  for  each  remote  terminal  are  assigned  to  a  single 
bit  within  a  16-bit  data  word.  Data  words  of  message  30  are  organized  in  a  cascade 
arrangement  for  each  remote  terminal.  There  are  three  classifications  of  remote  terminal 
faults;  Type  A,  Type  B,  and  Type  C.  The  highest  level  fault  reporting  is  for  the  remote 
terminal  itself,  and  these  are  classified  as  “Type  A”  faults.  Type  A  faults  are  located 
toward  the  front  of  message  30.  The  next  level  of  fault  data,  “Type  B”  is  assigned  to  a 
particular  components  of  a  remote  terminal.  Type  B  faults  comprise  the  middle  words  of 
message  30.  The  lowest  level  items  for  a  particular  remote  terminal  component  are 
classified  “Type  C”.  Type  C  faults  are  at  the  end  of  message  30.  “Type  C”  faults  are 
rolled  up  to  comprise  the  “Type  B”  faults.  In  turn.  Type  B  faults  are  rolled  up  to 
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comprise  the  Type  A  faults.  When  a  low  level  Type  C  fault  occurs,  it  in  turn  sets  a 
corresponding  Type  B  fault,  which  in  turn  sets  the  Type  A  fault.  Refer  to  Figure  14  for 
an  example  of  message  30  structure. 


Data  Word  1 

Data  Word  2 

Type  A 

Data  Word  3 

Component  1 

Data  Word  4 

Component  2 

Data  Word  5 

Type  B 

Component  3 

Data  Word  6 

Data  Word  7 

Data  Word  8 

Low  Level  Component  1  Items 

Data  Word  9 

Data  Word  1 0 

Data  Word  1 1 

Low  Level  Component  2  Items 

Data  Word  1 2 

Type  C 

Data  Word  1 3 

Data  Word  1 4 

Low  Level  Component  3  Items 

Data  Word  1 5 

Data  Word  1 6 

Data  Word  17 

Figure  14.  Sub-address  30  Organization 

E.  GRAPHICAL  FAULT  CORRELATION 

In  the  M1A2  system,  message  30  data  words  are  enumerated  according  to  the 
1553  vehicle  specification.  The  IMA  BIT  operations  use  the  information  extracted  from 
a  database  table  structure  as  defined  in  Table  5.  Refer  to  MS  Office  2000,  or  MS  Office 
XP  for  Access  database  features  and  operation. 
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Data  Field 

Attributes 

Usage 

Field  Name 

Data 

Type 

Field 

Size 

Default 

Value 

Required 

Allow 

Zero 

Length 

Indexed 

Unicode 

Compress 

DPNum 

Number 

Integer 

No 

No 

1553  Vehicle 
Protocol 

DPType 

Text 

50 

No 

No 

No 

No 

RT 

Number 

Byte 

No 

No 

SA 

Number 

Byte 

No 

No 

WordNum 

Number 

Integer 

No 

No 

StartBit 

Number 

Integer 

No 

No 

TotalBits 

Number 

Integer 

No 

No 

Owner 

Text 

50 

No 

No 

No 

Yes 

Fault 

Enumeration 

SubOwner 

Text 

30 

No 

No 

No 

Yes 

BIT/RPC 

Text 

10 

No 

No 

No 

No 

Message 

Text 

255 

No 

No 

No 

No 

Status 

Number 

Integer 

0 

No 

No 

Type 

Number 

Integer 

0 

No 

No 

*  All  other  attribute  fields  blank 


Table  6.  IMA  Database  Strueture 

All  low  level  eomponents  are  traeed  to  the  partieular  remote  terminal  eomponents. 
The  real-time  data  and  database  traeing  is  read,  correlated,  and  presented  graphically. 
For  example,  low  level  components  such  a  CID  1553  watchdog  timer  or  a  CID  1553  real¬ 
time  clock  fault  get  traced  to  the  1553  board  component.  If  either  one  of  these  is  set,  the 
M1A2  system  also  sets  the  Type  B  1553  board  fault  along  with  the  Type  A  terminal  fault 
for  the  CID.  What  the  IMA  user  sees  graphically  on  the  System  Display  Window,  is  a 
text  box  representation  of  the  last  detected  detail  failure  and  a  RED  flag  on  top  of  the 
CID  icon  in  the  System  Display  Window  (Figure  12).  The  IMA  user  then  clicks  the  CID 
icon  to  display  the  CID  component  graphical  display.  The  terminal  graphics  display,  in 
this  case  CID,  is  presented  in  a  fashion  that  represents  the  terminal  as  if  the  real  hardware 
box  was  open  (Figure  13).  At  this  component  level,  the  1553  board  would  show  RED. 
The  low  level  faults,  in  this  case,  1553  watchdog  timer  or  a  1553  real-time  clock  fault  are 
displayed  textually. 
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F.  FIT  SECTION 

The  M1A2  system  provides  a  FIT  capability.  FIT  is  executed  after  real-time 
faults  have  been  detected.  The  M1A2  FIT  process  correlates  documented 
troubleshooting  procedures  to  these  real-time  faults.  The  troubleshooting  procedures  are 
indexed,  numbered  1  through  n.  Based  on  the  faults  detected,  the  FIT  outputs  one  or 
more  TP  numbers.  Each  of  the  troubleshooting  procedures  is  an  ordered  set  of 
instructions,  when  performed,  designed  to  isolate  the  possible  component(s)  responsible 
for  the  faults  detected. 

G.  FIT  DATA 

Just  as  with  the  Graphical  Fault  Display,  IMA  connects  to  the  PC  shared  memory 
to  retrieve  real-time  1553  TP  FIT  data.  During  the  MIA2  FIT  execution  process  two 
1553  sub-addresses  are  used,  sub-address  10  and  sub-address  II.  Refer  to  Chapter  II  for 
the  1553  protocol.  The  M1A2  system  monitors  sub-address  10  for  the  user  initiation  of 
FIT.  As  FIT  executes,  TP  numbers  are  output  on  the  1553  data  bus  in  sub-address  II. 
Each  specific  procedure  index  is  assigned  to  a  single  bit  within  a  16-bit  data  word.  Refer 
to  Eigure  15  for  an  example  of  the  1553  16-bit  EIT  data  enumeration. 
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SUBADDRESS  1 1 


a: 


Data  Word  1 

<0  <0 

Data  Word  2 

Data  Word  3 

Data  Word  4 

Data  Word  5 

1000000000100000 

Data  Word  6 

Data  Word  7 

Data  Word  8 

Figure  15.  FIT  Data  Enumeration 

H,  IMA  FIT  GRAPHICS 

IMA  reads  the  real-time  FIT  data  from  sub-address  1 1 .  IMA  then  applies  bit-wise 
enumerations  to  extraet  the  eorresponding  TP  indexes.  Note  that  the  same  MS  Aeeess 
database  that  stores  the  BIT  fault  data  is  used  to  store  these  FIT  enumerations.  After  TP 
indexes  are  gathered  IMA  populates  a  GUI  sub  window  with  the  list  of  TPs  (see  Figure 
18). 

Onee  TPs  are  gathered,  real-time  1553  data  is  no  longer  needed.  Maintenanee 
erew  need  only  follow  the  step-by-step  instruetions  in  the  TP  to  pin  point  fault  sourees. 
Instead  of  requiring  the  maintenanee  crew  to  manually  shuffle  through  procedures  in  the 
hardcopy  manuals,  or  manually  scrolling  through  electronic  pdf  files,  the  IMA  provides 
hyperlinked  HTML  files  that  can  be  clicked  to  display  the  correct  page  in  the 
maintenance  manual.  To  provide  this,  the  IMA  uses  a  simple  static  relational  database. 
Note  that  this  is  the  same  database  that  contains  BIT  and  FIT  enumerations.  To  populate 


the  database  with  needed  hyperlink  information  a  series  of  conversion  and  parsing  was 
necessary,  as  illustrated  in  Figure  16. 


Figure  16.  Conversion  Process 

I.  GENERIC  HTML  CONVERSION 

Existing  maintenance  manual  documentation  (pdf  format)  is  converted  to  FITML. 
An  Adobe  add-on  product,  Magellan,  is  used  to  parse  the  pdf  maintenance  manual 
documentation.  The  product  parsed  each  pdf  page  of  each  manual  to  a  unique  HTML 
file.  These  unique  HTML  files  were  assigned  names  using  a  convention  that  including 
the  manual  volume,  section,  and  page. 
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J.  PARSE  PDF  TEXT  REFERENCES 

The  same  pdf  files  were  also  converted  to  straight  text.  This  allowed  text  parsing 
for  the  TP  items  themselves  as  well  as  other  internal  and  external  (different  manual 
volume)  page  references.  Within  each  HTML  page  there  could  exist  many  page 
references.  This  was  easily  handled  with  the  relational  database  structure.  All  page  or 
procedure  references  within  all  manuals  are  parsed  out  and  stored  within  the  database. 
TP  numbers  and  page  references  were  correlated  to  the  raw  HTML  page  and  to  the 
sectional  page  notation.  This  correlation  data  is  stored  in  the  MS  Access  database.  For 
all  identified  references,  the  HTML  file  was  updated  with  the  hypertext  attributes.  All 
HTML  files  along  with  the  database  reside  on  the  local  PC.  The  local  path  is  set  under 
the  File->Preferences  menu,  shown  in  Figure  17. 


Figure  17.  PDF  Text  Preference  Location 


Based  on  user  IMA  menu  selections  and  the  database,  appropriate  systems  manual 
pages  containing  the  needed  troubleshooting  procedures  are  presented.  An  illustration  of 
the  IMA  FIT  capabilities  is  shown  in  Figure  18  below  for  TP  code  333.  Clicking  on  the 
hyperlink  for  TP333  shown  in  Figure  18  yields  the  manual  page  3-315  Figure  19. 
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Figure  18.  TP  Code  333 
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IMA-E20-1-1_273.htm] 


1^  File  Edit  Status  View  Window  Help 


I  Manual  Name  Page 

Hull  TP  Number 

Turret  TP  Number  | 

|TM9-2350.288-20-1.1  |a 

1  TP  001  _2J 

|tpooi  _l|  ' 

TM9.2350-288-20  1-1 


X  Set  FIRE  EXTINGUISHER  2ND  SHOT  switch  to  OFF. 

X  Set  MASTER  PCWER  switch  to  OFF. 

X  Prepare  multimeter  for  ohms  test. 

X  Disconnect  2VV1 25-8yP1  from  J7  on  remote  switching 
module  1  (2A102)  roaoe  3-1006T 

X  Test  for  less  than  5  ohms  between  contact  B  and  contacts 
on  2W1 25-8yP5  listed  below; 

xA 

X  Connector  body 

Does  multimeter  show  less  than  5  ohms? 


3d _ 

X  Set  FIRE  EXTINGUISHER  2ND  SHOT  switch  to  OFF. 

X  Replace  engine  compartment  valve  and  bottle  assembly 
(second  shot)  fpaae  23-211. 

X  Verify  problem  is  solved. 


2W125-8/P5 


X Replace  branched  wiring  harness  2W125-8  fpaae  9-1 86'i. 
X  Verify  problem  is  solved. 


3d _ 

X  Connect  2W1 25-8/P5  to  J1  on  engine  second  shot  "re 
extinguisher  valve  fpaae  3-1 01 3T 

X  Replace  remote  switching  module  2A102  fpaae  9-72T 
X  Verify  problem  is  solved. 


3-315 


Figure  19.  Flyperlink  for  TP333 


> 
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V.  TEST  AND  EVALUATION 


No  formal  testing  was  conducted  during  IMA  development.  The  Visual  C++ 
Compiler  and  Debugger  tool  were  used  during  development.  Bug  tracking  and  software 
enhancements  were  kept  informally.  At  various  stages  during  development,  IMA 
modules  were  tested  at  the  integration  level  to  ensure  proper  operation  of  the  assembled 
code.  After  IMA  development,  the  test  effort  would  center  on  “functional”  or  “black¬ 
box”  testing.  “Glass-box”  or  “white-box”  test  methods  were  not  employed  because  of  the 
nature  of  IMA  itself  IMA  either  hyperlinked  to  proper  manual  page  or  it  did  not.  IMA 
either  reported  the  correct  system  failure  that  was  injected  or  it  did  not.  Quantitative  data 
would  be  gathered  to  evaluate  IMA  usage  versus  hardcopy  manual  usage. 


A,  TEST  GOALS 

The  IMA  test  goals  were  to  validate  the  IMA  fault  reporting  and  to  evaluate  the 
time  it  took  to  trace  TPs  using  hardcopy  manuals  usage  versus  the  hyperlinked  IMA 
manuals.  Test  goals  were  to  be  primarily  satisfied  by  the  demonstration  method.  Data 
will  be  injected  in  a  controlled  environment  and  IMA  will  be  expected  to  produce  known 
result.  With  regard  to  IMA  hyperlinking,  timing  analysis  will  be  used  in  conjunction 
with  the  demonstration  method. 

1.  Interject  BIT  faults  into  the  M1A2  system 

a.  Verify  proper  IMA  top  level  system  fiag(s) 

b.  Verify  proper  IMA  sub-system  fiag(s) 

c.  Verify  proper  IMA  BIT  fault  isolation  report(s) 

2.  Interject  FIT  faults  into  the  M1A2  system 

a.  Verify  proper  IMA  FIT  data  collection 

b.  Verify  proper  IMA  FIT  data  reporting 

3.  IMA  troubleshooting  procedure  hypertext  linking 

a.  Verify  page  referencing 

b.  Gather  timing  data  for  TP  tracing  using  hardcopy  manuals  usage  versus 


the  hyperlinked  IMA  manuals 
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B,  IMA  TEST  SETUP 

IMA  is  intended  for  eonneetions  to  real  system  hardware.  Fault  insertions  eannot 
be  aehieved  on  the  vehiele  at  the  lower  board  level  with  real  system  hardware.  Speeifie 
1553  terminal  emulations  were  employed  for  fault  insertions.  These  were  already  in 
plaee  in  the  System  Integration  Lab  (SIL)  beneh  for  the  M1A2.  The  M1A2  SIL  was  the 
environment  used  for  all  testing. 

1.  IMA  BIT  Capability 

To  verify  goals  for  the  IMA  BIT  eapability,  two  remote  terminal  eonfigurations 
within  the  M1A2  SIL  were  used.  In  one  eonfiguration,  the  DID  terminal  was  emulated. 
In  the  other  eonfiguration  the  GCDP  terminal  was  emulated.  The  eomplete  M1A2 
terminal  status  for  the  two  distinet  test  eonfigurations  is  shown  below.  The 
eorresponding  emulation  tool  appearanee  ean  be  viewed  in  Figure  20  and  Figure  21. 
a.  Simulated  DID  Configuration 


1553  Deviee 

Status 

Emulator  Appearanee  (Eig  #20) 

HEU 

Aetual 

Red  Diamond 

TEU 

Aetual 

Red  Diamond 

DID 

Emulated 

Green  Diamond 

CID 

Aetual 

Red  Diamond 

DECU 

Aetual,  with 
emulated  diserete  input 

Red  Diamond 

GCDP 

Aetual 

Red  Diamond 

b.  Simulated  GCDP  M1A2  Configuration 


1553  Deviee 

Status 

Emulator  Appearanee  (Eig  #21) 

HEU 

Aetual 

Red  Diamond 

TEU 

Aetual 

Red  Diamond 

DID 

Aetual 

Red  Diamond 

CID 

Aetual 

Red  Diamond 

DECU 

Aetual,  with 
emulated  diserete  input 

Red  Diamond 

GCDP 

Emulated 

Green  Diamond 
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2,  IMA  FIT  Capability 

To  verify  goals  for  the  IMA  FIT  capability,  only  one  remote  terminal 
configuration  within  the  M1A2  SIL  was  needed.  The  complete  M1A2  terminal  status  for 
the  test  configuration  is  shown  below. 


1553  Device 

Status 

Emulator  Appearance 

HEU 

Actual 

Red  Diamond 

TEU 

Actual 

Red  Diamond 

DID 

Actual 

Red  Diamond 

CID 

Actual 

Red  Diamond 

DECU 

Actual,  with 
emulated  discrete  input 

Red  Diamond 

GCDP 

Actual 

Red  Diamond 

3,  IMA  TP  Manual  Hyperlinking 

To  verify  goals  for  the  IMA  FIT  capability,  the  same  remote  terminal 
configuration  used  for  the  FIT  capability  was  also  used  for  the  IMA  TP  manual 
hyperlinking. 


C.  TEST  PROCEDURE 

1,  IMA  BIT  Capability 

With  the  M1A2  SIL  running  in  the  configuration  described  in  Section  V.B.l.a,  a 
known  set  of  BIT  faults  were  injected  via  the  DID  emulation.  In  Sub-address  #30  the 
following  faults  were  set  (see  Figure  20  for  the  DID  emulation); 

•  Data  word  5,  bit  5  (Graphics  Board  Dynamic  RAM) 

•  Data  word  6,  bit  15  (Display  Monitor) 

•  Data  word  4,  bit  1  (Graphics  Board) 

•  Data  word  3,  bit  0  (DID  Selftest  Status) 
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Figure  20.  Injected  BIT  Faults  For  DID 


With  the  controlled  data  inputs  injected  above,  the  IMA  is  launched  on  a  PC  that 
is  also  connected  to  the  1553  system  data  bus: 

a.  Verify  on  the  IMA  system.  Iru  window  that  DID  terminal  is  flagged  red. 

b.  Verify  on  the  IMA  did.  Iru  sub-system  window  that  DID  tactical  display 
and  tactical  graphics  board  are  flagged  red. 

c.  Verify  on  the  IMA  system.lru  window  that,  upon  clicking  the  large  “Error 
Message  Window”,  that  all  injected  DID  faults  can  be  viewed.  These 
appear  in  a  circular  scroll  list  on  successive  mouse  clicks. 

With  the  controlled  data  inputs  removed: 

d.  Verify  on  the  IMA  system.lru  window  that  DID  terminal  is  no  longer 
flagged  red. 

e.  Verify  on  the  IMA  did.  Iru  sub-system  window  that  DID  tactical  display 
and  tactical  graphics  board  are  no  longer  flagged  red. 

f  Verify  on  the  IMA  system.lru  window  that,  upon  clicking  the  large  “Error 
Message  Window”,  that  no  DID  faults  are  viewed. 
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Repeat  the  procedure  above  with  a  known  set  of  BIT  faults  injected  via  the  GCDP 
emulation.  In  Sub-address  #30  the  following  faults  were  set  (see  Figure  21  for  the  GCDP 
emulation); 

•  Data  word  4,  bit  0  (1553  Board  Type  3) 

•  Data  word  3,  bit  0  (GCDP  Selftest  Type  1) 

•  Data  word  5,  bit  0  (1553  Board  Watch-Dog  Timer) 

•  Data  word  6,  bit  15  (1553  Board  On  Line  Loop-Back) 


Figure  21 .  Injected  BIT  Faults  For  GCDP 
With  the  controlled  data  inputs  injected  above; 

a.  Verify  on  the  IMA  system.lru  window  that  GCDP  terminal  is  flagged  red. 

b.  Verify  on  the  IMA  gcdp.lru  sub-system  window  that  GCDP  1553  board  is 
flagged  red. 
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c.  Verify  on  the  IMA  system.lru  window  that,  upon  clicking  the  large  “Error 
Message  Window”,  that  all  injected  GCDP  faults  can  be  viewed.  These 
appear  in  a  circular  scroll  list  on  successive  mouse  clicks. 

With  the  controlled  data  inputs  removed; 

d.  Verify  on  the  IMA  system.lru  window  that  GCDP  terminal  is  no  longer 
flagged  red. 

e.  Verify  on  the  IMA  gcdp.lru  sub-system  window  that  GCDP  1553  board  is 
no  longer  flagged  red. 

f  Verify  on  the  IMA  system.lru  window  that,  upon  clicking  the  large  “Error 
Message  Window”,  that  no  GCDP  faults  are  viewed. 

2.  IMA  FIT  Capability 

IMA  PIT  reporting  capabilities  were  tested  using  a  third  test  environment  where 
DECU  faults  could  be  injected.  With  the  M1A2  SIE  running  in  the  configuration  as 
described  in  Section  V.B.2,  DECU  emulated  engine  data  for  the  DECU  data  was  set  to 
conflict  within  the  system.  Hence,  the  system  recognizes  a  faulty  DECU.  The  system 
BIT  check  was  run  and  as  expected  the  DECU  appeared  as  NOGO  after  the  system  BIT, 
refer  to  Pigure  22.  Paulty  equipment  must  exist  for  the  M1A2  system  to  output  TP 
reference  codes  during  system  PIT  execution.  IMA  PIT  testing  could  now  be  performed. 


Pigure  22.  DECU  BIT  Pail  on  CID 
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The  next  step  was  to  exeeute  a  system  FIT  eheek.  Before  initiating  the  FIT  eheek 
with  the  system  hardware,  the  IMA  FIT  aetion  was  initiated.  This  kieks  off  the  IMA  FIT 
monitoring  of  Sub-address  30.  This  extra  IMA  logie  was  neeessary  beeause  system  FIT 
data  is  only  valid  during  FIT  exeeution.  Automotive  (DECU)  related  TP  eodes  were 
expected  as  a  result  of  the  FIT  check. 

a.  Verify  the  IMA  FIT  capture  logic  retrieves  TP  code  information. 

b.  Verify  that  on  the  IMA  FIT  Output  Window  that  captured  TP  codes  match 
that  reported  by  the  real  system  hardware. 

3.  IMA  TP  Manual  Hypertext  Linking 

To  evaluate  the  IMA  hypertext  linking  capability,  the  same  FIT  report  TP  codes 
captured  during  the  DECU  EIT  reporting  validation  would  be  used,  TP  codes  272,  280, 
and  285.  The  test  method  was  to  have  three  different  subjects  navigate  through  the  hard 
copy  TP  manuals  and  flag  all  the  pages  referenced  in  each  TP  tree.  The  time  it  took  for 
all  flags  to  be  put  in  place  were  captured  to  be  analyzed.  Elagged  pages  would  also  be 
compared  to  the  IMA  hypertext  link  to  ensure  accuracy.  The  test  criteria  below  was  used 
for  the  test: 

•  Three  people  navigating  DECU  TP  codes  in  time 

•  Elag  all  page  references  for  the  TP  navigation  (known  path) 

•  Collect  the  end  times  when  all  flags  are  set 

D,  TEST  RESULTS/REPORTING 

The  following  table  summarized  all  IMA  test  results.  PC  screen  captures  of  the 
IMA  were  saved  during  testing.  These  screen  captures  illustrate  the  observed  results. 
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1. 


IMA  BIT  Capability  Test  Results 


IMA  Test  Results  Table 


Capability 

Criteria 

Reference 

Expected  result 

Observed  Result 

Comment 

IMA  BIT 
reporting 

V.C.l.a- 

DID 

DID  terminal  is  flagged 
red  on  IMA  system.  Iru 
window  when  faults 
injeeted 

As  Expected 

See  Eigure  23 

IMA  BIT 
reporting 

V.C.l.b- 

DID 

DID  taetical  display  and 
tactical  graphics  board 
are  flagged  red  on  IMA 
did.lru  sub-system 

window  when  faults 
injected 

As  Expected 

See  Eigure  24 

IMA  BIT 
reporting 

V.C.l.c- 

DID 

When  injected,  all  DID 
faults  can  be  viewed  by 
clicking  the  large 
“Error  Message 

Window”  on  the 

system.  Iru  window. 

As  Expected 

See  Eigure  25 

IMA  BIT 
reporting 

V.C.l.d- 

DID 

After  clearing  DID 
faults,  DID  terminal  is 
no  longer  flagged  red  on 
IMA  system.  Iru 

window. 

Red  DID  flag  not 
cleared.  IMA  restart 
was  required  to  clear 
flag  on  the  high  level 
system.lru  window. 

No  code  to 
reset/populate 
the  internal  GUI 
RT  flag  array  for 
the  active 

window. 

IMA  BIT 
reporting 

V.C.l.e- 

DID 

After  clearing  DID 
faults,  DID  tactical 
display  and  tactical 
graphics  board  are  no 
longer  flagged  red  on 
IMA  did.lru  sub-system 
window. 

As  Expected 

None 

IMA  BIT 
reporting 

V.C.l.f- 

DID 

After  clearing  DID 
faults,  no  DID  faults  are 
viewed  upon  clicking 
the  large  “Error 

Message  Window”  on 
the  system.lru  window. 

All  DID  faults  were 
visible  in  the  same 
circular  scroll  loop. 

No  code  to 
reset/clear  the 
RT  fault  array 
stored  for 

system.lru 
window. 

IMA  BIT 
reporting 

V.C.l.a- 

GCDP 

GCDP  terminal  is 
flagged  red  on  IMA 
system.lru  window 

when  faults  injected 

As  Expected 

See  Eigure  26 
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Capability 

Criteria 

Reference 

Expected  result 

Observed  Result 

Comment 

IMA  BIT 
reporting 

V.C.l.b- 

GCDP 

GCDP  1553  board  is 
flagged  red  on  IMA 
gcdp.lru  sub-system 

window  when  faults 
injected 

As  Expected 

See  Eigure  27 

IMA  BIT 
reporting 

V.C.l.c- 

GCDP 

When  injected,  all 
GCDP  faults  can  be 
viewed  by  clicking  the 
large  “Error  Message 
Window”  on  the 

system.  Iru  window. 

As  Expected 

See  Eigure  28 

IMA  BIT 
reporting 

V.C.l.d- 

GCDP 

After  clearing  GCDP 
faults,  GCDP  terminal  is 
no  longer  flagged  red  on 
IMA  system.  Iru 

window. 

Red  GCDP  flag  not 
cleared.  IMA  restart 
was  required  to  clear 
flag  on  the  high  level 
system.lru  window. 

No  code  to 
reset/populate 
the  internal  GUI 
RT  flag  array  for 
the  active 

window. 

IMA  BIT 
reporting 

V.C.l.e- 

GCDP 

After  clearing  GCDP 
faults,  GCDP  1553 
board  is  no  longer 
flagged  red  on  IMA 
gcdp.lru  sub-system 

window. 

As  Expected 

None 

IMA  BIT 
reporting 

V.C.l.f- 

GCDP 

After  clearing  GCDP 
faults,  no  GCDP  faults 
are  viewed  upon 

clicking  the  large  “Error 
Message  Window”  on 
the  system.lru  window. 

All  GCDP  faults  were 
visible  in  the  same 
circular  scroll  loop. 

No  code  to 
reset/clear  the 
RT  fault  array 
stored  for 

system.lru 
window. 
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2. 


IMA  FIT  Capability  Test  Results 


Capability 

Criteria 

Reference 

Expected  result 

Observed  Result 

Comment 

IMA  FIT 
reporting 

V.C.2.a 

TP  eode 

information  is 

captured  during 

system  FIT 

execution. 

As  Expected 

TP  codes  are 
populated  in 
the  FIT  Output 
Window.  See 
Figure  29 

IMA  FIT 
reporting 

V.C.2.b 

Captured  TP  codes 
match  that  reported 
by  the  real  system 
hardware 

IMA  reports  TP  codes 
272,  280,  285,  and 
605.  The  M1A2 

system  report  for  the 
Automotive  sub¬ 

system  is  illustrated  in 
Figure  25.  TP  codes 
are  272,  280,  and  285. 
Note  that  IMA  also 
reports  TP  code  605, 
this  is  valid  because 
the  system  also 

reported  an  additional 
cable  disconnect  TP 
code,  605,  under  the 
M1A2 

communications  sub¬ 
system. 

See  Figures  29 
and  30.  Both 
IMA  and  the 
system  report 
TP  codes  272, 
280,  285,  and 
605. 

IMA 

Hypertext 

linking 

V.C.3 

IMA  page 

references  are 

accurate  and  IMA 
hypertext  linking  is 
a  faster,  reliable 
method  for  TP 
manual  navigation. 

See  section  3  below. 

See  section  3 
below. 
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3,  IMA  Hypertext  Linking  Test  Results/Reporting 

Unfortunately,  the  test  subjeets  that  were  used  were  staff  engineers;  aetual  vehiele 
maintainers  were  unavailable  for  the  test.  The  engineers  were  familiar  with  the  manuals 
and  understood  the  eriteria  of  the  test. 

Eaeh  of  the  engineers  was  given  one  of  the  TP  eodes  to  traverse  a  speeified  path. 
Engineer  1  had  the  NO  path,  Engineer  2  had  the  YES  path  and  Engineer  3  used  the  IMA 
with  eombination  of  YES  and  NO  deeision  paths.  All  of  TP  eodes  had  an  equal  number 
deeision  steps  to  traverse  to  ensure  a  fair  test.  The  results  are  shown  below. 


TP  272  Manual 

TP  280  Manual 

TP  285  IMA 

ENG  1 

6  Min  32  See 

ENG  2 

6  Min  56  See 

ENG  3 

20  See 

This  by  no  means  a  seientifie  sample  of  data  but  it  does  suggest  that  the 
hyperlinked  TMs  are  more  maneuverable  than  the  paper  manuals.  Whether  the 
maintainers  would  have  performed  better  than  the  engineers  is  speeulative  at  this  time. 

4.  Problem  with  System  Buffer  Reset 

We  found  a  design  flaw  in  the  IMA  at  this  part  of  the  test.  The  system  buffer 
eould  not  be  reset.  So  to  run  sueeessive  tests  we  would  have  to  reboot  the  IMA  system 
eaeh  time.  This  will  be  addressed  in  the  next  version  of  the  software. 

Eow-level  BIT  fault  reporting  is  not  visible  to  the  M1A2  system  displays.  An 
external  1553  bus  monitor  was  eonneeted  on  the  1553  bus  to  allow  monitoring  of  the 
Sub-address  #30  fault  data  words  for  eaeh  1553  terminal  (shown  in  Eigure  22  and  Eigure 
23). 
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Figure  23.  DID  BIT  Results  on  IMA 

Fault  in  this  message  were  compared  to  the  faults  reported  via  the  IMA  for 
validation  (shown  in  Figure  24  and  Figure  25  below). 


Figure  24.  DID  BIT  Sub-system  Results  on  IMA 
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Graphics  Board  Dynamic  RAM 
Display  Monitor 

Graphics  Board 

DID  Selftest  Status 

Figure  25.  DID  BIT  Reports  from  IMA 

In  addition,  IMA  had  identified  the  speeifie  board  failure  in  each  fault  injected 
LRU  (shown  in  Figure  26  and  Figure  27)  below. 


Figure  26.  GCDP  BIT  Results  on  IMA 
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SS  IMA  -  [gcdp.lru] 


0  File  View  Status  Help  _  Ifll  x| 

Manual  Name  Page  Hull  TP  Number  Turret  TP  Number 

I  -e*  O  ]TM9-2350-2K-20-1-1  — 3  |tpooi  2I  |tpooi  2I  I 

^  ^1 


Start  FIT  | 

Stop  FIT  I 


TACT  DISPLAY 


TACT  GRAPHICS  BOARD 


PANEL  BOARD 


CONTROL  PANEL  LIGHTS/SWITCHES 


GUNNER'S  HANDLE 


POWER  SUPPLY 


BACK  TO 
MAIN  IMA 


Li^ _ I  ii 

start!  I  g  SYSTEM  BENCH |  UtlHty  Bus  Emulrtor  a,.,  |  *1  *  Test  Automation  To..,  |  V  Ima  system  GCDP  Palis...  |[0  IMA- Tgcdp-lru]  7:56AM 

Figure  27.  GCDP  BIT  Sub-system  Results  on  IMA 


1 553  Board  Type  3 


GCDP  Selftest  Type  1 


1553  Board  Watch-Dog  Timer 


1553  Board  On  Line  Loop-BK 


Figure  28.  GCDP  BIT  Reports  from  IMA 
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Figure  29.  DECU  FIT  Results  on  CID 


Figure  30.  DECU  IMA  EIT  Results 
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E,  TP  MANUAL  USAGE 

To  evaluate  hardcopy  manual  usage,  the  same  FIT  report  TP  codes  captured 
during  the  DECU  FIT  reporting  validation  were  used.  The  test  criteria  below  were  used 
for  the  test; 

•  Three  people  navigating  DECU  TP  codes  in  time 

•  Flag  all  page  references  for  the  TP  navigation  (known  path) 

•  Collect  the  end  times  when  all  flags  are  set 

Unfortunately,  the  test  subjects  were  staff  engineers;  actual  vehicle  maintainers 
were  unavailable  for  the  test.  The  engineers  were  familiar  with  the  manuals  and 
understood  the  criteria  of  the  test  (refer  to  Section  V.A  item  3  and  Section  V.C  item  3). 
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VI.  CONCLUSION 


In  designing  and  building  the  IMA,  we  attempted  to  provide  the  end  user  (the 
maintainer  in  our  case),  with  a  diagnostic  tool  that  went  beyond  what  was  provided  by  the 
Technical  Manuals  (TMs).  By  utilizing  the  MIA2  diagnostics  capability  in  conjunction 
with  an  enhanced  electronic  version  of  the  TMs,  the  IMA  would  arm  the  maintainer  with 
a  new  arsenal  of  tools  to  increase  his  capability  to  reduce  time  in  diagnosing  vehicles. 
The  key  thrust  in  the  development  of  the  IMA  was  to  reduce  or  eliminate  technical 
manuals  in  print,  reducing  possibly  of  mix-ups,  lost  pages,  and  reducing  update  costs. 
One  of  the  key  elements  in  the  design  was  not  to  increase  the  logistics  burden  to  the 
program  manager,  therefore,  the  use  of  the  SPORT  software  downloader  was  chosen,  as 
it  was  already  part  of  the  inventory. 


A,  LESSONS  LEARNED 

The  lesson  learned  during  development  of  the  IMA  was  requirements  creep. 
Throughout  the  requirement  and  design  phase  of  this  thesis  project,  management  of,  if 
you  will,  “the  bells  and  whistles”  became  paramount.  We  wanted  to  provide  the 
maintainer  as  many  tools  as  possible  while  keeping  in  mind  the  scale  of  project.  With 
this  said,  we  had  to  tone  down  what  to  include  in  this  phase  of  development.  The  end 
result  is  a  set  of  advanced  tools  that  presents  the  user/maintainer  greater  flexibility  and 
insight  into  1553  data  bus  message  passing  and  diagnostics. 

Having  the  actual  maintainers  perform  the  diagnostic  tests  from  start  to  finish 
would  have  been  the  ideal  test  environment  to  prove  paper  versus  computer.  Due  to  the 
war  effort,  finding  qualified  maintainers  to  participate  in  a  master’s  thesis  research  was 
impossible. 

It  is  the  author’s  sincere  hope  that  further  research  time  will  be  given  to  pursue 
and  convince  the  program  management  office  that  the  IMA  is  a  useful  and  timesaving 
device. 
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B,  FOLLOW  ON  WORK 

1.  Pre-Planned  Product  Improvement 

Once  the  IMA  has  proven  its  eapabilities  and  value  to  the  Army  maintenance  and 
support  activities  we  can  further  investigate  and  exploit  the  technology  that  is  available 
from  commercial  industry  to  further  enhance  IMA  capabilities.  Further  areas  of  interest 
would  be  prognostics,  Maintenance  Knowledge  Database  (MKD)  and  automated 
preventive  maintenanee  aetivities.  COTS  software  packages  sueh  as  Prognostic 
Framework  will  be  investigated  and  leveraged  to  enhance  system  eapabilities.  Adding 
prognostic  capability  will  preempt  eomponent  failures  and  improve  the  vehicle’s 
readiness.  Implementing  a  MKD  will  provide  various  types  of  information  sueh  as 
vehicle  repair  history  and  access  to  the  fleet  vehicle  repairs  that  are  similar  to  the 
diagnosed  problem.  The  MKD  will  also  provide  repairs  with  tips  and  methods  from 
other  Army  technicians.  It  will  also  have  the  capability  to  order  the  parts  needed  for  the 
repair  and  list  the  parts  that  were  ordered  in  the  past  to  fix  similar  problems.  The 
automated  preventative  maintenance  will  schedule,  maintain,  and  track  a  vehicle’s  usage 
through  system  logs  and  by  the  types  of  mission  the  vehieles  are  being  sent  on. 

2.  Removing  the  System  Buffer  Reset  Problem 

Further  development  of  the  IMA  must  include  reset  for  the  system  buffer.  As  we 
eneountered  during  the  testing  phase  when  injecting  the  faults  and  running  BIT  and  FIT 
tests  the  resulting  TP  codes  were  in  the  system  buffer  with  no  way  to  clear  them.  The 
only  method  was  to  re -boot  the  IMA  system  and  start  process  again. 
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